keyboardManager: Update layout index before keymap

Unfortunately, layouts and keymaps are not considered atomic data
even though they are closely related. Furthermore, these are async
operations that are not immediate to apply, and each of them result
in a plethora of updates down in Mutter (layout group being a subset
of keymaps).

Doing things in the current order, these updates do result in a
feedback loop, since the layout index is not changed altogether with
the keymap, but the keymap update is also seen as a layout change.

Even though it still does result in unnecessary intermediate updates,
changing the layout index first avoids the feedback loop, since it
will already match with the expectations after the ClutterKeymap is
updated.

This fixes deadlocked shell when using xkb options that trigger layout
changes through the ISO_Next_Group key emission, when the group change
also triggered a keymap update (e.g. moving to a different group
per KeyboardManager.MAX_LAYOUTS_PER_GROUP limits).

This does not fix being able to switch between all layouts, when
there is more than one group. This will be fixed in later commits.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8738
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3930>

diff --git a/js/misc/keyboardManager.js b/js/misc/keyboardManager.js
index 2ecc8facc08d1108702c210f427dd9aba7a320f9..37b4f29bfdccdff6d6fbcea117ca0c8c11cc2d1d 100644 (file)
--- a/js/misc/keyboardManager.js
+++ b/js/misc/keyboardManager.js
@@ -76,8 +76,8 @@ class KeyboardManager {
     }
 
     async _doApply(info) {
-        await this._applyLayoutGroup(info.group);
         await this._applyLayoutGroupIndex(info.groupIndex);
+        await this._applyLayoutGroup(info.group);
     }
 
     apply(id) {